Service provider certified device policy management

ABSTRACT

Various exemplary embodiments relate to a method performed by a policy server. The method includes: receiving a request for service, the request including an identification of user equipment; determining a user equipment type (TAC); evaluating a policy rule based on the user equipment type, the policy rule including a condition referencing at least one user equipment type; and responding to the request for service based on evaluation of the policy rule.

CROSS-REFERENCE TO RELATED APPLICATIONS

This application is related to the following co-pending application,which is hereby incorporated by reference for all purposes as if fullyset forth herein: application Ser. No. 14/034,878, filed on Sep. 24,2013, “RESIDENTIAL GATEWAY BASED POLICY.”

TECHNICAL FIELD

Various exemplary embodiments disclosed herein relate generally tocommunications networks.

BACKGROUND

Communications networks, in particular, mobile networks allow variousdevices to connect to the network in order to obtain communicationsservices. A subscriber identity module (SIM) card may be inserted intovarious devices in order to select the mobile network or move anexisting subscriber to a new device. Use of a SIM card allows users toswitch mobile networks. For example, users may switch a device sold byone network provider to the mobile network of another provider. Usersmay also attempt to connect imported devices to the mobile network. Theflexibility of SIM cards increases the number of devices that may beconnected to a mobile network.

SUMMARY

A brief summary of various exemplary embodiments is presented. Somesimplifications and omissions may be made in the following summary,which is intended to highlight and introduce some aspects of the variousexemplary embodiments, but not to limit the scope of the invention.Detailed descriptions of a preferred exemplary embodiment adequate toallow those of ordinary skill in the art to make and use the inventiveconcepts will follow in later sections.

Various exemplary embodiments relate to a method performed by a policyserver. The method includes: receiving a request for service, therequest including an identification of user equipment; determining auser equipment type; evaluating a policy rule based on the userequipment type, the policy rule including a condition referencing atleast one user equipment type; and responding to the request for servicebased on evaluation of the policy rule.

In various embodiments, the method further includes determining amarketing name for the user equipment, wherein the condition referencesthe at least one user equipment type according to the marketing name.The marketing name may correspond to a plurality of user equipmenttypes.

In various embodiments, the user equipment type is a type allocationcode (TAC) extracted from a user-equipment-info attribute value pair(AVP) received in the request for service.

In various embodiments, the condition references a plurality of userequipment types

In various embodiments, the method further includes determining that therequest for service is not related to a known subscriber; andauthorizing default services based on the user equipment type. Thedefault services may include a limit on at least one of an availabletime period and a data volume.

In various embodiments, the method further includes: authorizing adefault session configured to provide access to a service portal;storing the identification of user equipment in association with thedefault session; receiving, from the portal, a request foridentification of user equipment associated with the session; sendingthe stored identification of user equipment to the portal; receiving newsubscriber information including the identification of user equipment;and updating the session based on the new subscriber information. Themethod may further include determining that the request for service isnot related to a known subscriber, wherein the default session is basedon an unknown subscriber identifier and certified user equipment type.The method may further include storing an IP address for the defaultsession, wherein the request for identification of user equipmentassociated with the session includes the IP address.

Various exemplary embodiments relate to a non-transitorymachine-readable storage medium encoded with instructions executable bythe processor of a policy server for performing the above describemethod.

Various exemplary embodiments relate to a policy server including: aninterface configured to receive a service request initiated by a userequipment attaching to a mobile network, the service request including auser equipment identification; a device mapper configured to determine amarketing name of the device based on the user equipment identification;and a rules engine processor configured to evaluate conditions of policyrules and execute actions corresponding to true conditions, at least onepolicy rule including a condition based on the marketing name of thedevice.

In various embodiments, the device mapper includes a non-transitorymachine-readable storage medium storing a plurality of type allocationcodes, each type allocation code mapped to a marketing name.

In various embodiments, the condition of the at least one rule includesa certified device marketing name and the action of the at least onerule instructs the rules engine to allow a session providing service tothe user equipment. The policy server may further include a sessioninformation storage configured to store information regarding thesession including the marketing name of the user equipment; and anapplication programming interface configured to provide an externalservice portal access to the session information and configured toreceive subscriber information from the service portal.

Various exemplary embodiments relate to a method performed by a policyserver. The method includes: receiving a request for service, therequest including an identification of user equipment; authorizing adefault session configured to provide access to a service portal;storing the identification of user equipment in association with thedefault session; receiving, from the portal, a request foridentification of user equipment associated with the session; sendingthe stored identification of user equipment to the portal; receiving newsubscriber information including the identification of user equipment;and updating the session based on the new subscriber information.

Various exemplary embodiments relate to a method performed by a serviceportal. The method includes: receiving a request for new subscriberregistration from a user equipment; determining an IP address of theuser equipment; requesting, from a policy server, a user equipment type;determining a set of compatible subscriptions based on the userequipment type; receiving a selection of a compatible subscription fromthe user equipment; and sending new subscription information based onthe selected compatible subscription to the policy server.

It should be apparent that, in this manner, various exemplaryembodiments enable policy decisions based on user equipment device. Inparticular, by analyzing the TAC, a policy server may determine themarketing name of a device and provide policy according to the model ofthe device.

BRIEF DESCRIPTION OF THE DRAWINGS

In order to better understand various exemplary embodiments, referenceis made to the accompanying drawings, wherein:

FIG. 1 illustrates an exemplary subscriber network for providing variousdata services;

FIG. 2 illustrates a schematic diagram of an exemplary policy andcharging rules node (PCRN);

FIG. 3 illustrates an exemplary rule table;

FIG. 4 illustrates a flowchart showing an exemplary method for makingpolicy decisions based on user equipment type; and

FIG. 5 illustrates a message diagram showing an exemplary method ofproviding customized service plans.

DETAILED DESCRIPTION

As the number of available devices grows, mobile networks may sufferfrom compatibility issues. For example, users may install a SIM cardinto device that is not compatible with the network. An incompatibledevice may cause problems for the mobile network, such as, for examplesending repeated requests that consume network resources.

Identifying a model of a network device connecting to a mobile networkmay allow a network policy server, such as a policy and charging rulesnode (PCRN), to make policy decisions based on the type of networkdevice. For example, a policy server may limit network access tocertified devices that are known to be compatible with the mobilenetwork. A policy server may also provide certified devices with defaultservices regardless of the subscriber. In various embodiments, a policyserver may facilitate subscriber selection of customized service plansbased on the type of mobile device.

Referring now to the drawings, in which like numerals refer to likecomponents or steps, there are disclosed broad aspects of variousexemplary embodiments.

FIG. 1 illustrates an exemplary subscriber network 100 for providingvarious data services. Exemplary subscriber network 100 may be atelecommunications network or other network for providing access tovarious services. Exemplary subscriber network 100 may include userequipment 110, base station 120, evolved packet core (EPC) 130, packetdata network 140, application function (AF) 150, and service portal 160.

User equipment 110 may be a device that communicates with packet datanetwork 140 for providing the end-user with a data service. Such dataservice may include, for example, voice communication, text messaging,multimedia streaming, and Internet access. More specifically, in variousexemplary embodiments, user equipment 110 is a personal or laptopcomputer, wireless email device, cell phone, tablet, television set-topbox, or any other device capable of communicating with other devices viaEPC 130.

Base station 120 may be a device that enables communication between userequipment 110 and EPC 130. For example, base station 120 may be a basetransceiver station such as an evolved nodeB (eNodeB) as defined by 3GPPstandards. Thus, base station 120 may be a device that communicates withuser equipment 110 via a first medium, such as radio waves, andcommunicates with EPC 130 via a second medium, such as Ethernet cable.Base station 120 may be in direct communication with EPC 130 or maycommunicate via a number of intermediate nodes (not shown). In variousembodiments, multiple base stations (not shown) may be present toprovide mobility to user equipment 110. Note that in various alternativeembodiments, user equipment 110 may communicate directly with EPC 130.In such embodiments, base station 120 may not be present.

Evolved packet core (EPC) 130 may be a device or network of devices thatprovides user equipment 110 with gateway access to packet data network140. EPC 130 may further charge a subscriber for use of provided dataservices and ensure that particular quality of experience (QoE)standards are met. Thus, EPC 130 may be implemented, at least in part,according to various 3GPP standards. Accordingly, EPC 130 may include aserving gateway (SGW) 132, a packet data network gateway (PGW) 134, apolicy and charging rules node (PCRN) 136, and a subscription profilerepository (SPR) 138.

Serving gateway (SGW) 132 may be a device that provides gateway accessto the EPC 130. SGW 132 may be the first device within the EPC 130 thatreceives packets sent by user equipment 110. SGW 132 may forward suchpackets toward PGW 134. SGW 132 may perform a number of functions suchas, for example, managing mobility of user equipment 110 betweenmultiple base stations (not shown) and enforcing particular quality ofservice (QoS) characteristics for each flow being served. In variousimplementations, such as those implementing the Proxy Mobile IPstandard, SGW 132 may include a Bearer Binding and Event ReportingFunction (BBERF). In various exemplary embodiments, EPC 130 may includemultiple SGWs (not shown) and each SGW may communicate with multiplebase stations (not shown).

Packet data network gateway (PGW) 134 may be a device that providesgateway access to packet data network 140. PGW 134 may be the finaldevice within the EPC 130 that receives packets sent by user equipment110 toward packet data network 140 via SGW 132. PGW 134 may include apolicy and charging enforcement function (PCEF) that enforces policy andcharging control (PCC) rules for each service data flow (SDF).Therefore, PGW 134 may be a policy and charging enforcement node (PCEN).PGW 134 may include a number of additional features such as, forexample, packet filtering, deep packet inspection, and subscribercharging support. PGW 134 may also be responsible for requestingresource allocation for unknown application services.

Policy and charging rules node (PCRN) 136 may be a device or group ofdevices that receives requests for application services, generates PCCrules, and provides PCC rules to the PGW 134 and/or other PCENs (notshown). PCRN 136 may be in communication with AF 150 via an Rxinterface. As described in further detail below with respect to AF 150,PCRN 136 may receive an application request in the form of anAuthentication and Authorization Request (AAR) from AF 150. Upon receiptof AAR (not shown), PCRN 136 may generate at least one new PCC rule forfulfilling the application request.

PCRN 136 may also be in communication with SGW 132 and PGW 134 via a Gxxand a Gx interface, respectively. PCRN 136 may receive an applicationrequest in the form of a credit control request (CCR) (not shown) fromSGW 132 or PGW 134. As with AAR, upon receipt of a CCR, PCRN maygenerate at least one new PCC rule for fulfilling the applicationrequest. In various embodiments, AAR and the CCR may represent twoindependent application requests to be processed separately, while inother embodiments, AAR and the CCR may carry information regarding asingle application request and PCRN 136 may create at least one PCC rulebased on the combination of AAR and the CCR. In various embodiments,PCRN 136 may be capable of handling both single-message andpaired-message application requests.

Upon creating a new PCC rule or upon request by the PGW 134, PCRN 136may provide a PCC rule to PGW 134 via the Gx interface. In variousembodiments, such as those implementing the PMIP standard for example,PCRN 136 may also generate QoS rules. Upon creating a new QoS rule orupon request by the SGW 132, PCRN 136 may provide a QoS rule to SGW 132via the Gxx interface.

The PCRN 136 may also communicate with service portal 160 via anapplication programming interface (API) which will be described infurther detail below.

Subscription profile repository (SPR) 138 may be a device that storesinformation related to subscribers to the subscriber network 100. Thus,SPR 138 may include a machine-readable storage medium such as read-onlymemory (ROM), random-access memory (RAM), magnetic disk storage media,optical storage media, flash-memory devices, and/or similar storagemedia. SPR 138 may be a component of PCRN 136 or may constitute anindependent node within EPC 130. Data stored by SPR 138 may include anidentifier of each subscriber and indications of subscriptioninformation for each subscriber such as bandwidth limits, chargingparameters, and subscriber priority.

Packet data network 140 may be any network for providing datacommunications between user equipment 110 and other devices connected topacket data network 140, such as AF 150. Packet data network 140 mayfurther provide, for example, phone and/or Internet service to varioususer devices in communication with packet data network 140.

Application function (AF) 150 may be a device that provides a knownapplication service to user equipment 110. Thus, AF 150 may be a serveror other device that provides, for example, a video streaming or voicecommunication service to user equipment 110. AF 150 may further be incommunication with the PCRN 136 of the EPC 130 via an Rx interface. WhenAF 150 is to begin providing known application service to user equipment110, AF 150 may generate an application request message, such as anauthentication and authorization request (AAR) according to the Diameterprotocol, to notify the PCRN 136 that resources should be allocated forthe application service. This application request message may includeinformation such as an identification of the subscriber using theapplication service, an IP address of the subscriber, an APN for anassociated IP-CAN session, and/or an identification of the particularservice data flows that must be established in order to provide therequested service. AF 150 may communicate such an application request tothe PCRN 136 via the Rx interface.

Service portal 160 may be a device that provides a subscriber withaccess to information regarding the subscriber's account. For example,service portal 160 may be a server provided by a network operator. UE110 may connect to service portal 160 via packet data network 140 toview or change account information. Service portal 160 may be configuredfor communication with PCRN 136 or SPR 138 via an API that providesaccess to various functionality of PCRN 136. For example, service portal160 may use the API to obtain session information regarding a connectedsubscriber. As another example, service portal 160 may be allowed toupdate SPR 138 with changes to subscriber information based interactionwith a UE 110.

FIG. 2 illustrates a schematic diagram of an exemplary PCRN 200. PCRN200 may correspond to PCRN 136 shown in FIG. 1. PCRN 200 may beconfigured to make policy decisions based on the model of UE 110attempting to attach to the network 100. PCRN 200 may include a Gxinterface 205, a Gxx interface 210, an Rx interface 215, a device mapper220, a session information storage 225, rules engine 230, SPR 235 andAPI 240.

Gx interface 205 may be an interface comprising hardware and/orexecutable instructions encoded on a machine-readable storage mediumconfigured to communicate with a PGW such as PGW 134. Such communicationmay be implemented according to the 3GPP TS 29.212. Thus, Gx interface205 may receive requests for PCC rules and transmit PCC rules forinstallation. Gx interface 210 may further receive UE-originatedapplication requests, session requests, and event notifications in theform of a credit control request (CCR).

Gxx interface 210 may be an interface comprising hardware and/orexecutable instructions encoded on a machine-readable storage mediumconfigured to communicate with a SGW such as SGW 132. Such communicationmay be implemented according to the 3GPP TS 29.212. Thus, Gxx interface210 may receive requests for QoS rules and transmit QoS rules forinstallation. Gxx interface 210 may further receive UE-originatedapplication requests, session requests, and event notifications in theform of a credit control request (CCR).

Rx interface 215 may be an interface comprising hardware and/orexecutable instructions encoded on a machine-readable storage mediumconfigured to communicate with an AF such as AF 150. Such communicationmay be implemented according to the 3GPP TS 29.214. For example, Rxinterface 205 may receive a service request (AAR) from AF 150.

Device mapper 220 may include hardware or executable instructionsencoded on a machine-readable storage medium configured to determine amodel of user equipment. Device mapper 220 may extract information froma received message such as a CCR. In particular, device mapper 220 mayextract a User-Equipment-Info AVP, which may include anUser-Equipment-Info-Type AVP and an User-Equipment-Info-Value AVP.Device mapper 220 may ensure that the User-Equipment-Info-Type AVP is aknown type such as an international mobile station equipment identity(IMEI) or mobile equipment identifier (MEID). Device mapper 220 mayinterpret the User-Equipment-Info-Value AVP according to theUser-Equipment-Info-Type AVP. For example, for an IMEI, device mapper220 may extract the first eight digits of the IMEI as a Type AllocationCode (TAC). Device mapper 220 may then compare the TAC to a list ofknown devices. Each known device may be associated with a marketing namefor the device. PCRN 200 may include rules based on either the marketingname or the TAC.

Session information storage 225 may be a non-transitory machine-readablestorage medium configured to store session information for sessionsmanaged by PCRN 200. Session information storage 225 may store anyinformation received in a request in association with sessionidentifiers and PCC rules generated by PCRN 200. In particular,information for an IP-CAN session authorized by PCRN 200 may include asession identifier, either the User-Equipment-Info AVP, TAC, ormarketing name of the device, and an IP-address assigned to the UE 110for the session.

Rules engine 230 may include hardware or executable instructions encodedon a machine-readable storage medium configured to make decisions basedon available information and rules. Rules engine 230 may include variousrule sets that may be evaluated based on a particular event or context.For example, rules engine 230 may evaluate an attachment rule setwhenever PCRN 200 receives a message indicating a new device isattaching to the network 100. An attachment rule set will be furtherdescribed with respect to FIG. 3.

SPR 235 may be a subscriber profile repository device similar to SPR138. SPR 235 may be integrated with PCRN 200. SPR 235 may be accessed byrule engine 230 to provide subscriber information for use in evaluatingrules. SPR 235 may also be accessed via API 240 to provide subscriberinformation to another network element or receive updated subscriberinformation.

API 240 may include hardware or executable instructions encoded on amachine-readable storage medium configured to communicate with anexternal device such as a service portal 160. API 240 may provideauthorization features to ensure that the external device is allowed tocommunicate with PCRN 200. API 240 may make various features of PCRN 200available to an external device. For example, API 240 may provide accessto information stored in session information storage 225 or SPR 235. API240 may also allow service portal 160 to update SPR 235 with updatedsubscriber information.

FIG. 3 illustrates an exemplary rule table 300. Rule table 300 mayprovide rules to be evaluated by rules engine 230 in a particularsituation. For example, rule table 300 may be an attachment rule tablethat may be evaluated whenever a new device attaches to the network 100.Evaluation of rule table 300 may be triggered by receipt of an initialCCR message from PGW 134. Rule table 300 may include a name field 310, acondition field 320, and an action field 330. Rule table 300 may beconfigured by an operator of PCRN 200.

Name field 310 may indicate a name of the rule. The name of the rule maybe selected by the network operator to identify the rule. Name field 310may also include a unique identifier.

Condition field 320 may include one or more logical statements that maybe evaluated by rules engine 230. Condition field 320 may referenceinformation received in a message or stored at PCRN 200. For example, invarious embodiments, the marketing name received in a CCR message may beindicated asPCRN.IMEI.TAC(Gx-Message.User-Equipment-Info-Value.IMEISV.TAC).Marketing-Name.

Action field 330 may indicate one or more actions for PCRN 200 toexecute if the condition is true. For example, action field 330 mayindicate how PCRN 200 should respond to a request. Accordingly, rulestable 300 may be used to make policy decisions to select actions inresponse to requests.

Rules 340 may be rules configured by a network operator. For examplerule 340 a may be named “Certified Devices” and determine whether adevice attempting to attach to the network 100 is on a list of certifieddevices. For example, rule 340 a may allow access if the device has themarketing name “iPad”. Rule 340 a may include a plurality of marketingnames or TACs. A marketing name may be generic to several versions of adevice and PCRN 200 may use partial matching. As another example, rule340 b may be named “Blocked Devices” and determine whether a deviceattempting to attach to the network 100 is on a list of banned devices.If the device is on the banned list, PCRN 200 may deny the request toattach to the network. As another example, rule 340 c may be named“Certified Tablet; Unknown Subscriber.” Rule 340 c may determine thatthe device is a certified tablet device and the subscriber is unknownand provide default services to the device. Default services may be, forexample, a trial period for the device user to try the mobile network.For example, default services for a tablet device may include dataservice. As another example, rule 340 d may be named “Certified Phone;Unknown Subscriber.” Rule 340 d may determine that the device is acertified phone and the subscriber is unknown and provide default voiceservice to the device.

FIG. 4 illustrates a flowchart showing an exemplary method 400 formaking policy decisions based on user equipment type. The method 400 maybe performed by a policy service such as PCRN 136 or PCRN 200. Themethod 400 may begin at step 405 and proceed to step 410.

In step 410, the PCRN 200 may receive a CCR message requesting servicesfor a user equipment 110. The CCR message may include informationregarding the UE 110 including a User-Equipment-Info AVP, a subscriberidentifier, and an IP address of the UE 110.

In step 415, PCRN 200 may extract the User-Equipment-Info AVP from theCCR message. In step 420, PCRN 200 may determine the TAC based on theUser-Equipment-Info AVP. PCRN 200 may extract the eight digits of theTAC from the User-Equipment-Info-Value AVP based on theUser-Equipment-Info-Type AVP.

In step 425, PCRN 200 may determine a marketing name for the UE 110based on the TAC. The marketing name may be a commercial name of themodel of the device. The marketing name may apply to one or more modelsof a device. For example, the marketing name “iPad” may refer to anApple iPad, iPad 2, or iPad mini. PCRN 200 may also use partial matchingwith marketing names. For example an iPad2 or an iPad mini may bothmatch a rule using the name “iPad”. PCRN 200 may store any informationassociated with the UE 110, the CCR message, or the subscriber insession information storage 225. For example, PCRN 200 may store theuser identification, the IP address, the User-Equipment-Info-AVP orextracted elements, the marketing name, or any combination of thisinformation.

In step 430, PCRN 200 may determine whether the UE 110 is a certifieddevice. In various embodiments, PCRN 200 may use a rules engine 230 toevaluate attachment rules set 300 to determine whether UE 110 is acertified device. In various embodiments, a PCRN 200 may determinewhether the TAC or marketing name corresponds to a certified deviceusing to a list, filter, software module, or ASIC. Alternatively, PCRN200 may determine whether the TAC or marketing name is on a list ofbanned devices. PCRN 200 may operate on the assumption that any devicethat is not banned is certified. If the UE 110 is not a certifieddevice, the method 400 may proceed to step 435. If the UE 110 is acertified device, the method 400 may proceed to step 440.

In step 435, PCRN 200 may determine that the banned or not certifieddevice 435 should not be provided with service. Accordingly, PCRN 200may send a message such as a CCA message denying the received request.The method 400 may then proceed to step 455, where the method ends.

In step 440, PCRN 200 may determine whether the subscriber associatedwith UE 110 is a known subscriber. PCRN 200 may query SPR 138 or SPR 235with a subscriber identifier included in the CCR message to obtain asubscriber profile. If the subscriber identifier is not known to theSPR, PCRN may receive an indication that the subscriber identifier isunknown. If the subscriber is unknown, the method 400 may proceed tostep 445. If the subscriber is known, the method 400 may proceed to step450.

In step 445, the PCRN 200 may determine PCC rules for default servicesfor the UE 110. A service provider may provide default services to acertified device of an unknown subscriber in order to allow the user toexperience the network. For example, default services may be used todemonstrate data transfer rates or call quality. PCRN 200 may considerthe characteristics of the UE 110 when determining PCC rules for defaultservices. For example, PCRN 200 may provide data service for a tabletdevice with QoS settings that match the capabilities of the device. Asanother example, PCRN 200 may provide voice and data service for a smartphone. PCRN 200 may include the PCC rules in a CCA message in responseto the CCR message. Accordingly, PCRN 200 may send the PCC rules to PGW134 in order to provide the services. The method 400 may then proceed tostep 455, where the method ends.

In step 450, PCRN 200 may generate PCC rules based on the subscriberprofile of the known subscriber. PCRN 200 may generate the PCC rulesbased on a service plan selected by the subscriber. PCRN 200 may allowthe services selected by the subscriber. For example, PCRN 200 maygenerate the PCC rules by evaluating a different rule table withconditions based on elements of the subscriber profile. The method 400may then proceed to step 455, where the method ends.

FIG. 5 illustrates a message diagram showing an exemplary method 500 ofproviding customized service plans. The method 500 may be performed bythe various components of network 100 including UE 110, PGW 134, PCRN136, SPR 138, and service portal 160. As discussed above, SPR 138 may beintegrated with PCRN 136 as in PCRN 200.

In step 505, the UE device 110 may initiate attachment to the network100. The UE 110 may transmit a signal requesting attachment through basestation 120 and SGW 132. PGW 134 may receive the request and determinethat the UE 110 is requesting a new session. In step 510, PGW 134 maygenerate a CCR message to send to PCRN 136. The CCR message may includeinformation regarding the UE 110 including a User-Equipment-Info AVP anda subscriber identifier.

In step 515, PCRN 136 may extract and analyze the User-Equipment-InfoAVP. PCRN 136 may extract the TAC from the User-Equipment-Info-Value AVPand use the device mapper 220 to determine a marketing name for the UE110.

In step 520, PCRN 136 may request subscriber information from SPR 138based on the subscriber identifier included in the CCR message. In step525, SPR 138 may return available subscriber information. If SPR 138does not recognize the subscriber identifier, SPR 138 may indicate thatthe subscriber is unknown. For example, the subscriber identifier may beassociated with a new SIM card that has not been registered to anindividual. PCRN 200 may store any information associated with the UE110, the CCR message, or the subscriber in session information storage225. For example, PCRN 200 may store the user identification, the IPaddress, the User-Equipment-Info-AVP or extracted elements, themarketing name, or any combination of this information.

In step 530, PCRN 136 may evaluate policy rules to determine an actionfor the CCR message. PCRN 136 may evaluate an attachment rule set thatincludes rules for evaluating an initial CCR message. PCRN 136 mayevaluate the condition portion of each rule using the information in theCCR message, the marketing name of the UE 110, and subscriberinformation from SPR 138. As discussed above regarding FIG. 3, PCRN 136may determine whether to allow or deny the request based upon whetherthe UE 110 is a certified device. PCRN 136 may also determine whether toprovide an unrecognized subscriber with default services based uponwhether the UE 110 is a certified device. In various embodiments, PCRN136 may also determine that the UE 110 is eligible only for redirectservice. For example, if the subscriber unknown or is known but theaccount is expired or out of credit, PCRN 136 may determine that the UE110 should be provided with redirect services.

In step 535, PCRN 136 may respond to the CCR message with a CCA message.If PCRN 136 determines that the attachment request should be denied,PCRN 136 may send a CCA message with no PCC rules. If PCRN 136determines that the request should be granted, PCRN 136 may generate PCCrules and establish an IP-CAN session. If PCRN 136 determines that theattachment request from a known subscriber should be allowed, PCRN 136may generate PCC rules based on subscriber information to include in theCCA message. If PCRN 136 determines that default services should beprovided, PCRN 136 may include default PCC rules corresponding to theselected default services. If PCRN 136 determines that redirect servicesshould be provided, PCRN 136 may provide PCC rules that only allow theUE 110 to access the service portal 160. PCRN 136 may send the PCC rulesto PGW 134 for enforcement.

In step 540, UE 110 may attempt to communicate using network 100. Basedon the redirect PCC rules, PGW 134 may redirect UE 110 to service portal160. For example, PGW 134 may send an HTTP redirect to UE 110 with theaddress of the service portal 160. Service portal 160 may then receive arequest from UE 110. The request may be an HTTP request for a webpage.

In step 545, service portal 160 may request information from PCRN 136using the API 240. In particular, service portal 160 may request sessioninformation from PCRN 136 for the UE 110. Service portal 160 mayidentify the UE 110 using the IP address of the UE 110. The IP addressmay be associated with the IP-CAN session established by the PCC rulesin step 535. In step 550, PCRN 136 may determine the requested sessioninformation based on session information storage 225. PCRN 136 may sendthe information to service portal 160 using the API 240. The informationmay include the user-equipment-info AVP or the marketing name of the UE110.

In step 555, service portal 160 may generate customized plans for thesubscriber based on information regarding UE 110. Service portal 160 mayoffer service plans corresponding to the functionality of UE 110. Forexample, service portal 160 may offer a data only plan if UE 110 is atablet device.

In step 560, service portal 160 may send UE 110 information regardingthe customized plans. For example, UE 110 may send a webpage thatdisplays properties and prices for the customized plans. In step 565, UE110 may send the user's selection of a plan and payment information toservice portal 160. In various embodiments, UE 110 may send subscriberinformation in order to create a new account for the subscriber. Serviceportal 160 may verify the received information and charge for theselected plan.

In step 570, service portal 160 may send updated subscriptioninformation to SPR 138. In various embodiments where SPR 138 isintegrated with PCRN 136, service portal 160 may use API 240 to send theupdated subscription information. In other embodiments, SPR 138 mayinclude its own API or use a communications protocol for receivingupdated subscription information.

In step 575, PCRN 136 may request the subscriber record from SPR 138. Instep 580, SPR 138 may provide the updated subscription informationincluding the details regarding the selected plan.

In step 585, PCRN 136 may reevaluate the policy rules based on theoriginal CCR or an update CCR and the updated subscription information.PCRN 136 may generate new PCC rules to provide the services included inthe selected plan. In step 590, PCRN 136 may send the new PCC rules toPGW 134 for enforcement. UE 110 may then be able to access the servicesaccording to the selected plan. The method 500 may then end.

According to the foregoing, various exemplary embodiments provide forpolicy decisions based on user equipment device. In particular, byanalyzing the TAC, a policy server may determine the marketing name of adevice and provide policy according to the model of the device.

It should be apparent from the foregoing description that variousexemplary embodiments of the invention may be implemented in hardware.Furthermore, various exemplary embodiments may be implemented asinstructions stored on a machine-readable storage medium, which may beread and executed by at least one processor to perform the operationsdescribed in detail herein. A machine-readable storage medium mayinclude any mechanism for storing information in a form readable by amachine, such as a personal or laptop computer, a server, or othercomputing device. Thus, a machine-readable storage medium may includeread-only memory (ROM), random-access memory (RAM), magnetic diskstorage media, optical storage media, flash-memory devices, and similarstorage media.

It should be appreciated by those skilled in the art that any blockdiagrams herein represent conceptual views of illustrative circuitryembodying the principals of the invention. Similarly, it will beappreciated that any flow charts, flow diagrams, state transitiondiagrams, pseudo code, and the like represent various processes whichmay be substantially represented in machine readable media and soexecuted by a computer or processor, whether or not such computer orprocessor is explicitly shown.

Although the various exemplary embodiments have been described in detailwith particular reference to certain exemplary aspects thereof, itshould be understood that the invention is capable of other embodimentsand its details are capable of modifications in various obviousrespects. As is readily apparent to those skilled in the art, variationsand modifications can be affected while remaining within the spirit andscope of the invention. Accordingly, the foregoing disclosure,description, and figures are for illustrative purposes only and do notin any way limit the invention, which is defined only by the claims.

What is claimed is:
 1. A method performed by a policy server, the methodcomprising: receiving a request for service, the request including anidentification of user equipment; determining a user equipment type;evaluating a policy rule based on the user equipment type, the policyrule including a condition referencing at least one user equipment type;responding to the request for service based on evaluation of the policyrule; authorizing a default session configured to provide access to aservice portal; storing the identification of user equipment inassociation with the default session; receiving, from the portal, arequest for identification of user equipment associated with thesession; sending the stored identification of user equipment to theportal; receiving new subscriber information including theidentification of user equipment; and updating the session based on thenew subscriber information.
 2. The method of claim 1, further comprisingdetermining a marketing name for the user equipment, wherein thecondition references the at least one user equipment type according tothe marketing name.
 3. The method of claim 2, wherein the marketing namecorresponds to a plurality of user equipment types.
 4. The method ofclaim 1, wherein the user equipment type is a type allocation code (TAC)extracted from a user-equipment-info attribute value pair (AVP) receivedin the request for service.
 5. The method of claim 1, wherein thecondition references a plurality of user equipment types.
 6. The methodof claim 1, further comprising: determining that the request for serviceis not related to a known subscriber; and authorizing default servicesbased on the user equipment type.
 7. The method of claim 6, wherein thedefault services include a limit on at least one of an available timeperiod and a data volume.
 8. The method of claim 1, further comprising:determining that the request for service is not related to a knownsubscriber, wherein the default session is based on an unknownsubscriber identifier and certified user equipment type.
 9. The methodof claim 1, further comprising: storing an IP address for the defaultsession, wherein the request for identification of user equipmentassociated with the session includes the IP address.
 10. A policy servercomprising: an interface configured to receive a service requestinitiated by a user equipment attaching to a mobile network, the servicerequest including a user equipment identification; a device mapperconfigured to determine a marketing name of the device based on the userequipment identification; a rules engine processor configured toevaluate conditions of policy rules and execute actions corresponding towhen conditions are true, at least one policy rule including a conditionbased on the marketing name of the device; respond to the request forservice based on evaluation of the policy rule; authorize a defaultsession configured to provide access to a service portal; store theidentification of user equipment in association with the defaultsession; receive, from the portal, a request for identification of userequipment associated with the session; send the stored identification ofuser equipment to the portal; receive new subscriber informationincluding the identification of user equipment; and update the sessionbased on the new subscriber information.
 11. The policy server of claim10, wherein the device mapper comprises a non-transitorymachine-readable storage medium storing a plurality of type allocationcodes, each type allocation code mapped to a marketing name.
 12. Thepolicy server of claim 10, wherein the condition of the at least onerule includes a certified device marketing name and the action of the atleast one rule instructs the rules engine to allow a session providingservice to the user equipment.
 13. The policy server of claim 12,further comprising: a session information storage configured to storeinformation regarding the session including the marketing name of theuser equipment; and an application programming interface configured toprovide an external service portal access to the session information andconfigured to receive subscriber information from the service portal.14. A non-transitory machine-readable storage medium encoded withinstructions executable by a processor of a policy server, thenon-transitory machine-readable storage medium comprising instructionsfor: receiving a request for service, the request including anidentification of user equipment; determining a user equipment type;evaluating a policy rule based on the user equipment type, the policyrule including a condition referencing at least one user equipment type;responding to the request for service based on evaluation of the policyrule; authorizing a default session configured to provide access to aservice portal; storing the identification of user equipment inassociation with the default session; receiving, from the portal, arequest for identification of user equipment associated with thesession; sending the stored identification of user equipment to theportal; receiving new subscriber information including theidentification of user equipment; and updating the session based on thenew subscriber information.
 15. The non-transitory machine-readablestorage medium of claim 14, further comprising instructions fordetermining a marketing name for the user equipment, wherein thecondition references the at least one user equipment type according tothe marketing name.
 16. The non-transitory machine-readable storagemedium of claim 15, wherein the user equipment type is a type allocationcode (TAC) extracted from a user-equipment-info attribute value pair(AVP) received in the request for service.
 17. The non-transitorymachine-readable storage medium of claim 14, further comprisinginstructions for: determining that the request for service is notrelated to a known subscriber; and authorizing default services based onthe user equipment type.
 18. The non-transitory machine-readable storagemedium of claim 14, further comprising instructions for: determiningthat the request for service is not related to a known subscriber,wherein the default session is based on an unknown subscriber identifierand certified user equipment type; and storing an IP address of thedefault session, wherein the request for identification of userequipment associated with the session includes the IP address.